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This  document  briefly  presents  the  major  arguments  supporting 
the  need  for  the  Software  Technology  for  Adapatable,  Reliable 
Systems  (STARS)  program.  The  STARS  program,  part  of  the 
Department  of  Defense's  Software  Initiative,  covers  all  aspects  of 
the  software  life  cycle  from  both  technical  and  management 
viewpoints.  It  is  intended  to  provide  better  management 
practices,  Improve  software  acquisition  strategies,  improve  the 
underlying  software  technologies,  increase  personnel  skill  levels, 
create  more  powerful  development  and  maintenance  tools,  increase 
the  extent  to  which  tools  are  used,  and  make  advances  in  both 
software  system  methodology  and  software  theory  (120).  Figure  1  is 
a  graphic  overview  of  the  arguments  for  STARS  and  their 
relationships  to  one  another. 

Each  section  opens  with  a  summary  of  the  major  points  of  the 
argument  addressed  in  the  section.  A  brief  discussion  of  the 
argument  with  citations  to  the  evidence  that  supports  the  argument 
follows.  Rather  than  interrupt  paragraphs  by  citing  references  at 
the  end  of  each  sentence,  they  are  often  grouped  at  the  end  of  the 
discussion  of  a  particular  argument.  Other  references  to  articles 
and  documents  about  STARS  include  (90)-(112),  ( 137)— ( 140) . 

2.0  Future  MCCR  System  Requirements 

Future  requirements  for  software  within  the  DoD  will  be  so 
severe  that  without  improvements  in  software  technology,  the  DoD 
will  be  unable  to  meet  future  needs.  The  points  of  this  future 
requirements  argument  are  summarized  as  follows.  Software  is 
becoming  an  increasingly  Important  component  of  mission  critical 
computer  resource  (MCCR)  systems.  The  number,  complexity,  and 
criticality  of  functions  performed  by  software  in  such  systems  are 
all  increasing.  Furthermore,  there  is  a  growing  manpower  shortage 
in  the  computer  field  that  will  compound  future  requireme  ’ts 
unless  ways  are  found  to  increase  the  productivity  of  computer 
personnel . 


2.1  Software  Requirements 

The  last  decade  has  seen  a  trend  toward  greater  use  of 
computers  in  virtually  all  weapon  and  support  systems.  Almost 
every  item  of  defense  equipment  has  one  or  more  computer  subsystem 
which  controls  its  operation  in  some  mission-critical  fashion. 

From  the  avionics  suite  of  the  F/A-18  aircraft  to  the  fire  control 
system  of  the  Ml  tank,  from  the  complex  information  processing 
networks  of  the  AEGIS  fleet  air  defense  system  to  the  guidance  and 
control  system  of  the  MAVERICK  air-to-ground  missile,  whether  a 
tiny  chip  in  PATRIOT  or  a  roomful  of  stand-alone  mainframes  in  the 
World  Wide  Military  Command  and  Control  System  (WWMCCS) ,  the 
computer  is  present.  Accompanying  this  massive  infusion  of 
computer  hardware  into  defense  systems  is,  of  course,  the  software 
which  makes  it  work  (67). 


Figure  1 


ARGUMENT  OVERVIEW 


Given. 

Threat  Assessment  National  and  Service  Policies, 
Strategies,  and  Plans 


Some  facts  Illustrate  the  increasing  importance  of  software 
to  weapon  systems.  The  Electronic  Industries  Association 
estimates  OoD  expenditures  on  mission  critical  software  in  1984  to 
be  $9  billion  and  predicts  that  it  could  reach  $32  billion  by  1990 
(1).  A  review  of  the  FY8S  OoD  budget  presented  to  Congress  by 
Secretary  Weinberger  suggests  that  at  least  75%  of  the  programs 
listed  in  that  review  have  a  software  component  (2).  Among  the 
programs  to  begin  in  the  1985-1989  time  frame,  it  can  be  estimated 
that  at  least  80%  will  have  a  software  development  component  (3). 
In  addition,  over  70%  of  the  technologies,  functions,  and  systems 
identified  in  five  DoD  and  Service  long  range  plans  will  require 
software  (4). 


Not  only  will  there  be  more  software  in  the  future,  but 
software  will  be  responsible  for  more  functions.  Figure  2 
demonstrates  the  growth  in  software  demand,  in  millions  of  object 
instructions  generated,  across  four  generations  of  the  U.S.  manned 
space  flight  program  as  increasing  numbers  of  functions  were 
automated.  There  is  a  clear  trend  toward  automation  through 
software  of  more  weapon  system  operations,  such  as  guidance, 
control,  surveillance,  intelligence,  communication,  and  navigation 
(5).  Furthermore,  the  power  of  each  automated  function  is 
growing.  For  example,  the  current  AEGIS  air  defense  system  can 
track  in  excess  of  200  targets  while  the  Ballistic  Missile  Defense 
System  is  planned  to  track  and  discriminate  tens  of  thousands  of 
targets  (6)  -  (7). 

The  future  will  see  greater  complexity  as  a  result  of  the 
trend  toward  Integration  of  functions  for  such  purposes  as  sharing 
of  data.  The  LHX  helicopter,  currently  in  the  planning  stages, 
illustrates  this  trend  toward  integration.  Unlike  existing 
helicopters  which  have  no  fusion  and  little  information 
integration  capability,  the  LHX  will  have  multiple  sensors 
integrated  into  a  single  display.  This  information  integration 
capability  and  other  software  will  enable  it  to  be  a  single  pilot 
aircraft  (8). 


Increases  in  software  functionality  and  complexity  imply  that 
software  will  be  Increasingly  responsible  for  mission  success. 

Very  high  reliabilites  will  therefore  be  required  of  future 
systems.  For  example,  the  need  has  been  estimated  for  the 
probability  of  failure  in  avionics  of  10”®  per  10  hours  flight 
operation  (9). 


DoD's  software  requirements  are  not  the  only  ones  that  are 
Increasing  as  demonstrated  by  increases  in  software  sales  over  the 
past  20  years.  During  the  period  from  1963  to  1983,  roughly  20 
percent  of  the  growth  in  industry  revenues  occured  in  the  16  year 
period  from  1963  to  1979  and  80  percent  of  the  growth  occured  in 
the  last  four  years  since  1979.  From  1981  to  1983  packaged 
software  grew  at  a  40  percent  annual  rate.  This  compared  to 
increases  of  26  percent  for  integrated  systems  and  16  percent  for 
custom  software  for  that  period  (142). 
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2.2  Manpower  Shortage 


The  total  amount  of  software  that  the  DoD  needs  to  build  is 
well  beyond  the  capability  of  the  number  of  software  engineers 
that  can  reasonably  be  expected  to  be  available,  using  current 
software  development  methods.  According  to  a  recent  Department  of 
Commerce  study  (63),  the  600,000  to  700,000  programmers  and 
systems  analysts  in  the  U.S.  have  not  been  able  to  fill  the 
dramatic  increase  in  demand  for  their  services  that  resulted  from 
the  rapid  growth  in  the  use  of  computers.  This  increased  demand 
has  caused  their  salaries  to  rise  at  an  eight  to  ten  percent 
annual  rate  since  1978  (63).  The  current  U.S.  gap  between  demand 
and  supply  has  been  estimated  in  terms  of  50,000  to  100,000 
software  professionals,  and  if  nothing  is  done,  this  gap  could 
become  860,000  to  1,000,000  software  professionals  by  1990  (10)  - 
(11% 

During  the  years  1979  through  1982,  employment  in  software 
products  (packaged  software)  and  professional  services  (including 
custom  programming)  expanded  at  a  40  percent  average  annual  rate. 
Even  during  the  recession  years  of  1980  to  1982,  overall  software 
industry  employment  grew  by  17  percent.  The  software  products 
sector  had  the  highest  growth  rate  of  any  sector  during  the 
1981-1983  period,  increasing  threefold  from  22,000  to  68,000 
employees  (63). 

The  National  Science  Foundation  ( NSF )  projects  an  8.9Z  - 
12. 3Z  annual  growth  rate  for  defense  requirements  for  computer 
specialists  as  opposed  to  a  5.4Z  -  6.4Z  growth  rate  for  non 
defense  requirements  for  computer  specialists  (12).  NSF  also 
predicts  that  the  total  shortfall  for  computer  specialists  will  be 
in  the  15  to  30  percent  range  (about  115,000  to  140,000)  by  1987 
(12). 

The  life  of  some  software,  especially  large  military  system 
software  can  be  as  long  as  15  to  20  years.  For  these  systems,  60 
to  75  percent  of  the  costs  incurred  during  the  entire  life  cycle 
can  be  attributed  to  maintenance.  Some  experts  estimate  that 
about  20  percent  of  this  phase  consists  of  error  correction  and 
the  remaining  80  percent  consists  of  changes  and  enhancements.  In 
many  large  organizations  that  develop  their  own  programs,  over  one 
half  of  staff  time  may  be  devoted  to  these  functions,  diverting 
scarce  resources  from  new  development  (63). 

NSF  contends  that  personnel  shortages  in  the  computer  science 
area  can  only  be  alleviated  by  large  inflows  of  experienced 
personnel.  Although  the  computer  occupations  traditionally  have 
been  very  flexible  in  terms  of  accepting  workers  from  other 
fields,  complex  computer  applications  increasingly  demand  graduate 
degrees.  Therefore,  continued  high  transfer  rates  from  other 
occupations  may  be  difficult  to  sustain,  especially  as  advanced 
applications  are  introduced  in  areas  such  as  CAD/CAM,  information 
technology,  telecommunications,  and  the  sophisticated  modeling 
encouraged  by  development  of  the  supercomputer  (13).  The  shortage 
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of  computer  specialists  will  be  even  more  dramatic  as  software 
requirements  increase  in  the  future,  as  is  projected  (14). 


An  alternative  to  alleviating  the  personnel  shortage  with 
large  inflows  of  experienced  personnel  is  to  increase 
productivity.  Much  of  the  literature  points  to  a  need  to  increase 
the  productivity  of  analysts  and  programmers  in  the  face  of  these 
growing  workloads  and  shortages  of  qualified  people  (15)  - 
(17% 

To  date,  tools  that  improve  the  quality  and  increase  the 
quantity  of  software  personnel  work  include  high-level  languages, 
software  development  systems,  and  application  generators.  The 
Department  of  Commerce  report  notes,  however,  that  the  most 
progress  to  date  has  been  made  in  coding,  an  area  representing 
only  10  percent  of  the  development  effort. 

During  the  1960's,  the  annual  growth  rate  in  software 
productivity  averaged  about  8  to  9Z  due  largely  to  the  transition 
from  assembly  language  to  higher  order  language  software 
development  (128).  Higher  order  languages  generally  improve 
productivity  by  reducing  the  number  of  source  code  lines  (129). 
Programmer  productivity  may  be  increased  by  as  much  as  5  times 
when  a  suitable  high-level  language  is  used  (132).  For  example, 

E . A.  Nelson  has  shown  a  3-to-l  productivity  improvement  for  high 
level  language  (133). 

To  date,  the  adoption  of  software  engineering  methods  (or 
modern  programming  practices)  has  lagged  behind  the  need  for  more 
efficient  organization  of  software  production.  Similarly,  the 
growth  of  programmer  productivity  has  been  slow  in  relation  to  the 
need  for  more  programs  (63). 


2  . 3  Summary  of  Future  Software  Technolof 
Requirements 


State  of  Practice 


Figure  1  outlines  this  argument  as  follows.  Future  MCCR 
system  requirements  imply  future  software  requirements  that 
dramatically  exceed  present  requirements  and  capabilities. 
Moreover,  a  growing  manpower  shortage  compounds  the  problem. 


Software  Technology  State  of  Practice  (Current) 


The  current  state  of  practice  is  having  problems  meeting 
current  requirements.  As  a  1985  Air  Force  Studies  Board  report 
(123)  notes , 


In  spite  of  numerous  past  research  and  development  endeavors 
related  to  software  engineering  tools  and  methodologies,  the 
Air  Force  continues  to  experience  problems  in  obtaining 
required  performance,  quality,  and  productivity  while 
controlling  cost  and  schedules  of  large  software  based 
systems  (123). 
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Other  sources  support  Che  observation  that  the  problems  in 
software  development  and  support  are  many  and  varied.  They 
include  an  Inability  to  project  the  size  or  cost  of  software  in 
DoD  programs,  deficiencies  in  project  management,  and  ineffective 
test  and  evaluation  techniques.  These  and  other  problems  combine 
to  cause  cost  escalation  and  deployment  delays.  The  net  result  is 
unnecessary  lengthening  of  the  lead  time  required  to  meet  new 
enemy  threats.  Function  is  reduced  and  quality  suffers  as  the 
demand  for  new  systems  increases.  The  final  product  can  be  an 
ineffective  or  unsuitable  system.  If  improvements  are  not  made, 
it  is  reasonable  to  expect  more  failures  in  operational  weapon 
systems  in  the  near  future  (19). 

3 . 1  General  Problems  with  the  State  of  Practice 

Often,  weapon  system  requirements  and  schedules  are  not  met 
because  of  problems  with  mission  critical  software.  A  1982  DoD 
task  force  on  software  problems  observed  four  major  categories  of 
software  problems  facing  the  DoD: 

o  life  cycle 
o  production  environment 
o  product 

o  technical  and  management  professionals  (20). 

The  task  force  subcategorized  life  cycle  problems  into 
problems  with: 

o  requirements  definition  and  analysis 
o  management  of  life  cycle  activities 
o  software  acquisition 
o  software  product  assurance 
o  transitions  in  the  life  cycle  (20). 

Support  environment  problems  that  the  task  force  identified 
center  around  the  lack  of  disciplined  methods  and  development  and 
support  tools.  Furthermore,  it  observed  that  the  failure  to  reuse 
software  results  in  a  high  degree  of  re-invention  in  software 
development  and  higher  costs.  The  task  force  also  stated  that 
capital-investment  in  support  environments  has  been  insufficient 
(20). 


Problems  with  the  software  product  cited  by  the  task  force 
include  the  following.  The  software  product  does  not  always  meet 
the  need  for  which  it  was  developed.  The  lack  of  good  analytical 
models  and  hard  empirical  data  on  software  make  it  difficult  to 
estimate  cost  and  productivity.  Poor  designs  and  inadequate 
documentation  contribute  to  product-related  problems  (20). 

The  task  force  found  problems  relating  to  personnel  Including 
an  Inadequate  supply  of  qualified  managers  and  professionals  with 
a  wide  range  of  skills  and  experience.  In  addition,  present 
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incentives  favor  migration  of  skilled  personnel  from  job  to  job 

(20). 


A  study  of  the  current  state  of  practice  on  eight  software 
intensive  systems  (seven  government  and  one  commercial)  found  that 
five  of  the  development  efforts  were  considered  to  be  successful 
while  three  were  not.  The  data  gathered  does  not  support  the 
common  belief  that  developments  that  utilize  new  technology  will 
succeed  when  others  fail.  However,  it  does  point  to  some  common 
problems  with  the  current  state  of  practice  (21). 

One  observation  is  that  the  susceptibility  to  requirements 
definition  problems  is  increasing.  This  is  because  in  each  system 
studied,  software  was  being  used  to  implement  functions  that  had 
never  before  been  attempted.  Further,  the  capabilities  being 
implemented  by  software  are  becoming  more  varied  and  critical  to 
mission  success.  In  spite  of  the  importance  of  the  requirements 
definition  process,  few  systematic  techniques  and  little  automated 
support  are  used  for  these  activities.  The  problem  of  changing 
requirements  compounds  other  problems  found  in  the  current  state 
of  practice  (21). 

In  the  systems  studied,  the  transition  of  responsibility  for 
software  support  from  the  developing  organization  (usually 
commercial)  to  the  Post  Deployment  Software  Support  (PDSS) 
activity  (usually  governmental)  typically  did  not  occur  without 
problems  (21).  For  example,  on  one  of  the  projects,  new  tools 
were  developed  for  post  deployment  support.  It  should  be  noted 
however,  that  the  tools  developed  do  not  support  activities 
specific  to  the  PDSS  environment.  In  fact,  it  was  felt  that  the 
same  tools  Would  have  been  beneficial  during  the  initial 
development.  In  addition,  the  original  documentation  was  of  poor 
quality  and  has  been  upgraded  or,  in  cases  where  it  did  not  exist, 
created  (119). 

3 . 2  Problems  Estimating  the  Cost  and  Size  of  Software  in  the  DoD 

One  of  the  fundamental  problems  of  the  current  DoD  software 
business  is  the  Inability  to  accurately  measure  its  size. 
Productivity  Improvement  and  future  software  size  estimates  have 
meaning  only  in  comparison  to  current  figures.  A  1974  report 
states  that  "reliable  information  on  most  software  and  ADP  costs 
in  DoD  is  unavailable  in  a  clearly  identifiable  form"  (22).  In 
1979,  this  finding  was  confirmed  by  the  President's  Reorganization 
Project  on  Federal  Data  Processing  which  said  that  the  total 
dollar  value  of  computer  resources  in  the  DoD  is  unknown  (23). 

Isolating  software  cost  data  for  weapons  systems  remains  a 
problem  in  1984  since  a  separate  line  item  for  software  does  not 
exist  in  the  DoD  budget.  Instead,  it  is  treated  as  part  of 
individual  weapons  systems.  Major  software  developments  and 
modifications  are  part  of  RDT&E  funds,  while  software  maintenance 
activities  are  included  in  Operation  and  Maintenance  funds.  Even 
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DoD  program  managers  sometimes  do  not  know  how  much  is  being  spent 
for  software  on  their  programs  (24). 


A  1983  study  of  25  U.S.  and  Japanese  organizations  comprising 
some  69  projects  found  that  although  nearly  all  projects  collect 
data,  little  of  it  becomes  part  of  corporate  memory  to  be  used 
beyond  the  project  it  was  collected  for.  Moreover,  in  contrast  to 
their  Japanese  counterparts,  U.S.  companies  rarely  use  this  data 
for  post  mortem  analyses  of  projects.  In  particular,  companies 
experiment  with  cost  and  size  estimation  models,  although,  at  the 
time  the  study  was  done,  no  one  trusted  them  enough  to  use  them  in 
proposals.  Non-standard  definitions  of  types  of  data  are  also  a 
problem  (18). 

The  problem  of  estimating  software  costs,  staffing 
requirements,  and  schedules  was  observed  in  the  study  of  the 
current  state  of  practice  of  eight  software  intensive  systems. 

The  size  of  the  software  effort  was  consistently  underestimated 
and  the  productivity  of  the  people  overestimated  (21). 

Similarly,  the  software  cost  history  for  an  Air  Force  command 
and  control  software  project  shows  that  the  "best  and  final  offer” 
on  which  the  winning  bidder's  contract  was  obtained  was  a  little 
over  25%  of  the  original  cost  expectation,  based  on  '‘opportunistic 
assumptions  and  claims,”  but  the  subsequent  "series  of 
realizations”  resulted  in  escalating  costs  and  in  final  costs  that 
were  10  times  the  winning  bid  (and  almost  three  times  the  original 
cost  expectation)  (136). 

3 . 3  Project  Management  Problem 

Another  chronic  problem  area  in  the  current  state  of  practice 
is  project  management.  Several  technical  weaknesses  exist  at  all 
levels  in  the  DoD's  ability  to  measure,  track,  and  control 
software  over  its  life  cycle.  These  weaknesses  inhibit  the 
achievement  of  the  management  control  that  is  needed  over 
software.  A  recent  survey  of  software  engineering  project 
management  problems  found  that  13  of  20  hypothesized  problems 
actually  are  important  problems  that  face  software  engineering 
project  managers.  The  problems  can  be  broadly  classed  as 
planning,  organizing,  staffing,  directing,  and  controlling 
problems.  The  survey  found  that  software  engineering  project 
personnel  do  not  generally  agree  on  how  to  solve  these  major 
problems.  Moreover,  less  than  10%  of  the  100  universities 
surveyed  offer  any  courses  which  present  a  substantial  amount  of 
material  on  software  engineeerlng  project  management  problems 
although  most  professors  seemed  to  feel  that  more  classroom  time 
should  be  allocated  to  these  problems  (25).  A  separate  survey 
found  that  companies  offer  little  training  in  the  area  of  project 
management  in  comparison  to  technical  education  (18). 

DoD,  industry,  and  university  respondents  to  a  1982 
questionnaire  on  software  technology  agreed  that  the  most 
important  software  problem  is  finding  and  keeping  qualified 


personnel.  This  was  perceived  as  such  sore  of  a  problea  chan 
measuring  their  competence  or  making  best  use  of  them.  The 
respondents  also  agreed  that  the  second  most  important  problea  is 
poor  definition  of  goals  and  measures  (i.e.,  software 
requirements).  With  few  exceptions,  all  respondents  ranked  the 
managerial-related  problems  in  the  top  half  of  the  problem  list 
(26). 

Other  problems  attributable  to  project  management  Include  the 
limited  use  of  software  standards  and  tools.  Standards  vary 
within  a  single  organization  because  the  software  technology  group 
doing  data  collection,  modelling  resource  usage,  and  generating 
standards  and  practice  documents  does  not  have  direct  authority  to 
enforce  adherence  to  software  engineering  practices  on  projects. 
Software  standards  are  often  low  and  vary  across  a  company  because 
there  is  no  one  person  at  the  head  of  a  project  organization 
making  software  decisions  (18). 

Likewise,  tool  use  is  relatively  low  across  the  industry. 
Tools  are  most  frequently  used  during  the  code  and  unit  test 
phase,  in  contrast  to  the  requirements  or  maintenance  phases  in 
which  fewer  tools  are  used.  Corporate  management,  owing  to  a 
limited  software  background,  is  not  sympathetic  to  the  use  of 
tools.  Often  a  corporate  focal  point  for  tool  selection, 
deployment,  and  evaluation  does  not  exist.  Perhaps  most 
importantly,  tools  are  most  often  bought  with  project  funds 
forcing  projects  to  adopt  both  the  risk  and  expenditure  for  the 
tool  and  training.  Tool  use  in  Japan  is  more  widespread,  mainly 
because  tools  are  paid  for  out  of  overhead,  increasing  knowledge 
and  use  of  the  tool  throughout  a  company  and  lowering  the  risk  to 
any  individual  project  (18). 

3 . 4  Test  and  Evaluation  Problems 

Test  and  evaluation  (T&E)  is  yet  another  problem  area  for  the 
current  state  of  practice.  The  complexity  of  most  defense  systems 
software,  coupled  with  the  fact  that  the  software  development 
process  in  not  a  routine,  regularized,  clerical  process  which  can 
be  easily  organized,  controlled,  and  graded,  leads  to  a  situation 
in  which  quantitative  approaches  to  T&E  are  difficult.  The 
criticality  of  most  software  applications  makes  the  quantitative 
measurement  of  performance  and  reliability  absolutely  necessary 
(68). 

According  to  a  1983  report  of  the  Software  Test  and 
Evaluation  Project  (STEP),  many  problems  combine  to  limit  the 
effectiveness  of  current  Defense  practices  in  software  test  and 
evaluation.  These  Include:  (1)  insufficient  financial  and 
personnel  resources,  (2)  difficulty  in  selecting  the  best  testing 
strategy  available  for  a  given  application,  (3)  lack  of 
availability  of  testing  tools,  and  (4)  difficulty  of  evaluating 
early  development  testing  since  the  results  of  these  tests  are 
rarely  documented  or  reported.  All  of  these  problems  are 
amplified  by  frequent  modifications  to  requirements.  When  budgets 


are  cut  or  schedules  slip,  testing  and  quality  assurance 
activities  are  the  first  casualties. 


Among  the  recommendations  made  by  STEP  to  Improve  the  current 
state  of  practice  In  software  testing  are  recommendations  to 
develop  automated  tools  for  software  T&E  and  recommendations  for 
support  of  development  and  basic  research  which  have  long-term 
benefits  for  software  test  and  evaluation  (27). 

Another  1983  study  of  25  organizations  found  that  all  of  the 
projects  surveyed  did  reviews  to  a  greater  or  lesser  extent  and 
agree  that  they  work.  Integration  testing  for  the  most  part 
consists  of  stress  testing.  Among  short-term  recommendations  made 
by  the  report  were  that  the  review  process  needs  improvement.  For 
the  long  term,  the  report  recommended  the  development  of  a  test 
and  evaluation  methodology  (18). 

3 . 5  Operation  Problems 

These  and  other  problems  with  the  current  state  of'  practice 
can  result  In  final  products  that  fail  to  operate  correctly. 
According  to  a  1981  report,  “major  U.S.  weapon  systems  are 
becoming  more  expensive  at  an  alarming  rate  and  they  seldom  if 
ever  work  well  and  reliably  In  operational  surroundings"  (29).  As 
computers,  and  software  In  particular,  become  Increasingly 
critical  components  of  weapon  systems,  malfunctions  can  result  in 
immediate  danger,  especially  in  MCC&  applications. 

Some  examples  of  software  problems  in  the  area  of  defense 
indicate  the  potential  scope  of  the  problem.  The  F-18  aircraft 
had  problems  with  a  computer-controlled  missile  launch.  NORAD 
alerted  U.S.  forces  about  incoming  Soviet  missiles  after  detecting 
the  moon.  A  computer  glitch  caused  a  Navy  warship's  three-inch 
gun  to  fire  in  the  opposite  direction  from  Its  intended  target 
(28). 


A  software  bug  caused  an  F-14  to  fly  off  an  aircraft  carrier 
into  the  North  Sea  (28).  Another  F-14  was  lost  to  an 
uncontrollable  spin  that  was  traced  to  tactical  software.  Yet 
another  F-14  looped  as  a  result  of  an  ill-advised  one-line  code 
patch.  Fortunately  that  bug  was  caught  in  simulation  (121). 

The  first  version  of  the  F-16  navigation  software  inverted 
the  aircraft  whenever  it  crossed  the  equator.  Fortunately,  this 
was  caught  in  simulation  testing  (122).  The  F-16  flight  software 
at  one  point  was  unable  to  right  the  plane  when  it  was  exactly 
upside  down.  The  program  had  to  choose  between  rolling  right  and 
rolling  left  and  somehow  deadlocked  (121). 


•  . 
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3.6  Summary  of  Software  Technology  State  of  Practice  (Current) 

There  is  evidence,  therefore,  that  the  state  of  practice  is 
having  problems  producing  software  to  meet  current  requirements. 
Furthermore,  indications  are  that  software  is  expensive  to  produce 
in  terms  of  time,  personnel,  and  financial  resources,  although  it 
is  at  present  difficult  to  know  the  exact  cost  of  software  to  the 
DoD.  Many  problems  can  be  attributed  to  software  management,  but 
there  is  not  general  agreement  on  how  to  solve  such  problems  and 
university  courses  do  not  devote  the  time  to  these  problems  that 
professors  agree  they  deserve.  Test  and  evaluation,  especially 
crucial  to  software  reliability,  is  another  area  in  which  the 
state  of  practice  needs  help.  Software,  as  a  major  component  of 
weapons  is  increasingly  cited  as  a  cause  of  weapon  systems 
failures . 

4.0  Gap  Between  Current  State  of  Practice  and  Future  State  of 
Practice  Requirements 

If  the  current  state  of  practice  does  not  meet  current  needs, 
it  will  not  be  able  to  meet  future  needs  either.  As  Figure  1 
shows,  there  is  a  gap  between  the  future  software  technology  state 
of  practice  requirements  and  the  current  software  technology  state 
of  practice.  This  gap  must  be  reduced  if  the  O.S.  is  to  see 
improvement  in  software  development. 

The  U.S.  can  close  the  gap  between  required  software  capacity 
and  the  current  state  of  practice  by  exploiting  software 
technology  that  is  now  emerging  (see  section  5.3)  and  by  fostering 
R&D  in  new  software  technologies  to  meet  future  requirements.  The 
software  factory  concept  is  one  example  of  a  state-of-the-art 
software  technology  that  has  shown  gains  in  programmer 
productivity.  However,  maturation  time  for  software  technology 
currently  averages  15-20  years  (66).  By  accelerating  the 
transition  of  state-of-the-art  software  technologies  into  the 
state  of  practice,  the  DoO  can  reduce  labor  intensiveness  and 
latent  defects,  and  improve  predictability,  performance,  and 
responsiveness  to  changing  threats  (46)  and  (69). 

4.1  Japanese  Software  Factory 

One  example  of  a  software  technology  that  promises  gains  in 
productivity  if  it  is  incorporated  into  the  state  of  practice  is 
the  specialized  Japanese  "Software  Factory".  Specific 
productivity  and  quality  figures  on  Japanese  software  factory 
results  can  be  found  in  (70)  -  (72). 

As  an  illustration,  the  productivity  rate  at  Toshiba's  Fuchu 
Works'  software  factory  has  increased  14Z  annually  since  1976, 
reaching  an  average  of  2870  Instructions  per  programmer  per  month 
in  1981.  Prior  to  this,  from  1972-1976,  instructions  per 
programmer  per  month  averaged  1318.  This  software  factory 
attributes  it's  high  productivity  to  a  return  on  its  Investment  in 


software  tools  and  computer  networks,  reuse  of  modules  validated 
through  previous  applications,  and  its  quality  assurance  plan 
(73).  Thus,  introducing  such  technologies  into  the  state  of 
practice  can  improve  the  ability  to  produce  software. 


4.2  Technoloi 


Maturation 


Research  indicates  that  bringing  a  technology  to  the  point  of 
maturation  where  it  is  popularized  and  disseminated  to  a  large 
portion  of  the  technical  community  generally  has  taken  more  than 
15-20  years.  This  Includes  time  for  research  and  concept 
formulation,  development  and  prototyping,  enhancement  and 
exploratory  use,  and  dissemination  (74).  Software  technology 
maturation  case  studies  upon  which  this  observation  is  based  are 
(32)  -  (44).  Another  study  indicates  that  4-8  additional  years 
may  be  required  to  propagate  that  technology  throughout  a  large 
organization  (75). 


Certain  factors  that  inhibit  or  facilitate  the  maturation  of 
technolof  f  can  be  identified  and  exploited.  Particularly 
important  to  technology  maturation  are  a  recognized  need,  a 
receptive  target  community,  and  a  believable  demonstration  of 
cost/benefit.  Well-designed  channeling  of  attention  and  support, 
an  articulate  advocate,  prior  success,  incentives,  technically 
astute  managers,  readily  available  help,  latent  demand, 
simplicity,  and  Incremental  extensions  to  current  technology  also 
facilitate  the  maturation  process  (76). 


For  example,  technological  R&D  can  be  made  more  productive  by 
understanding  and  exploiting  the  S-curve  phenomenon.  Too  often. 
Instead  of  viewing  technological  changes  in  a  long-term  strategic 
context  and  managing  it  accordingly,  managers  focus  on  short-term 
remedies.  This  tendency  is  reinforced  by  other  factos  that  favor 
the  pursuit  of  existing  technologies  and  tend  to  suppress  timely 
exploitation  o-f  innovative  alternatives  (141). 


In  the  earliest  phases  of  a  new  technology,  progress  and 
therefore,  R&D  productivity  is  slow.  As  the  technology 
progresses,  so  does  productivity,  reaching  a  maximum  at  the 
midpoint  of  the  curve.  It  is  at  this  point,  before  the  S-curve 
flattens  out,  that  managers  should  be  thinking  of  getting  onto  a 
new  S-curve  where  the  slope  ahead  is  steeper.  Figure  3 
illustrates  this  concept  (141). 


Making  the  transition  to  a  new  technology  is  both  risky  and 
difficult,  but  the  most  common  error  is  poor  timing.  To  preserve 
long-term  strategic  flexibility,  management  should  begin  to 
explore  technological  alternatives  when  roughly  half  the  full 
potential  of  the  current  technology  has  yet  to  be  exploited  (141). 


Unfortunately,  common  business  management  tools  and  practices 
often  mask  this  phenomenon.  Management  systems,  marketing 
approaches,  and  financial  analyses  tend  to  reward  short-term 
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performance  based  on  incremental  advances  over  the  competition 
(141). 


Forecasts  beyond  a  3-  or  4-year  horizon  are  usually 
unreliable,  discriminating  against  a  decision  to  invest  in  a  move 
to  a  new  technological  S-curve  where  cash  flows  in  early  years 
look  less  attractive.  The  portfolio  approach  to  resource 
allocation  tends  to  emphasize  the  allocation  of  resources  among 
existing  opportunities,  rather  than  the  generation  of  new  ones 
(141).  Thus,  the  role  exists  for  the  U.S.  to  make  the  large  step 
to  the  next  S-curve. 

This  is  just  one  example  of  how  understanding  and  exploiting 
the  technology  maturation  process  can  hasten  improvements  in  the 
software  technology  state  of  the  art.  Thus  the  technology 
maturation  process  provides  the  basic  context  needed  for 
transitioning  technology  into  widespread  use. 


4.3  Technology  Transition 


Technology  transition  activities  are  planned,  overt  actions 
taken  to  move  a  piece  of  technology  into  widespread  use.  The 
challenge  is  to  find  ways  of  introducing  new  technologies  faster 
in  order  to  produce  better  software  more  efficiently.  A  recent 
workshop  (77)  addressed  the  issue  of  software  engineering 
technology  transfer.  Specifically  it  looked  at: 


(1)  ways  of  evaluating  software  technologies  and  the 
technology  transfer  process  itself; 


(2)  training  as  a  technology  transfer  vehicle; 


(3)  processes  required  for  effective  software  engineering 
technology  transfer  and  the  vehicles  that  might  be  used  to 
implement  such  processes;  and 


(4)  behavioral  aspects  of  software  technology  transfer. 


It  determined  that  an  important  obstacle  to  technology 
transfer  is  the  lack  of  a  coherent  and  well  defined  software 
engineering  product  life  cycle  process.  Common  understanding  and 
agreement  of  a  software  engineering  product  life  cycle  is 
necessary  in  order  to  effectively  carry  out  the  technology 
transfer  process.  This  process  consists  of: 

o  identifying  available  technologies  and  their  costs  and 
benefits ; 

o  overcoming  resistance  to  change; 

o  selecting  appropriate  vehicles  for  technology  transfer 

(depending  on  the  life  cycle  phase); 
o  integrating  multiple  technologies  across  time  and 

o  overcoming  proprietary  restrictions. 


Some  possible  transfer  vehicles  include: 
o  education, 

o  training, 

o  tool  provision, 

o  personnel  transfer, 

o  management  edict, 

o  measurement, 

o  consulting, 

o  quality  circles, 

o  documentation, 

o  contracts, 

o  rewards  and  incentives, 

o  publicity  and  advertising, 

o  demonstrations, 

o  experiments, 

o  pilot  projects, 

o  planning  mechanisms, 

o  competition  and  challenge, 

o  human  interface  and 

o  technical  interaction  (77). 

Thus,  the  opportunity  exists  to  accelerate  the  propagation  of 
state-of-the-art  software  technologies  into  the  state  of  practice 
and  significantly  improve  the  DoD's  capacity  to  produce  defense 
software. 


4 . 4  Summary  of  Gap  Between  Current  State  of  Practice  and  Future 
State  of  Practice  Requirements 


As  evidenced  by  the  Japanese  software  factory,  the  potential 
exists  for  state-of-the-art  software  technologies  to  Improve  the 
state  of  practice.  However,  based  on  studies  of  other  software 
technologies,  the  natural  maturation  of  a  software  technology  can 
take  15  to  20  years,  too  long  to  improve  the  state  of  practice  in 
the  near-term.  The  potential  exists  to  accelerate  this  process  by 
undertaking  technology  transition  activities. 


5.0  STARS  Program  Fills  Gap  and  Meets  Need 


Significant  basic  technology  exists  and  the  defense  software 
community  is  poised  to  exploit  it.  A  software  improvement  program 
is  necessary  to  effect  changes  in  the  software  state  of  practice 
in  order  to  meet  future  needs.  As  Figure  1  shows,  such  a  program 
requires  the  contributions  of  DoD  activities.  Industry,  and 
academia  as  well  as  unexploited  state-of-the-art  technologies. 
Bringing  state-of-the-art  technologies  to  the  state  of  practice 
can  help  close  the  gap. 


Since  the  accelerating  pace  of  computing  technology  is  too 
fast  and  too  capital  intensive  for  any  single  organization  to  keep 
up  with  alone  (78)  -  (87),  a  number  of  DoD  and  private  sector 
programs  have  been  initiated  to  improve  the  software  technology 
state  of  practice.  Articles  (78)  -  (87)  strongly  imply  that 


16 


cooperation  among  Governments,  professional  societies,  and  major 
commercial  enterprises  and  centrally  managed  financial  resources 
are  essential  for  the  survival  of  Industrial  nations.  A  centrally 
managed  effort  is  therefore  necessary  to  achieve  the  required 
capability  by  the  time  the  DoD  needs  it. 

A  centrally  managed  program  and  funding  source  (supplemented 
by  existing  defense  laboratory  programs  and  industry  1R&D 
(Independent  research  and  development)  investment),  with  much  of 
the  actual  work  being  contracted  through  or  performed  by  DoD 
laboratories  and  by  weapon  system  programs,  would  offer  the  great 
advantages  of  elimination  of  unnecessary  duplication  and  gaps, 
together  with  a  central  focus  for  identification  of  opportunities 
and  program  advocacy. 

5.1  STARS 

As  a  central  focal  point,  the  STARS  program  can  help  assure 
that  the  DoD  has  the  technology  it  needs,  when  it  needs  it, 
without  unnecessary  duplication  of  effort.  The  STARS  program 
defines,  plans,  develops,  demonstrates,  integrates,  evaluates,  and 
disseminates  tri-service  software  technology  (118). 


STARS  is  s 
upon  individual 
Ada  program  and 
demonstrate  and 
computer-aided 
mechanisms  for 
agency  sponsore 
Commanders'  sof 
resulting  from 
(114). 


pecifically  designed  to  mesh  closely  with  and  build 
Service  and  defense  agency  programs,  including  the 
the  Software  Engineering  Institute  (SEI).  It  will 
evaluate  the  feasibility  of  new  techniques  such  as 
software  support  systems.  STARS  will  produce 
implementation  and  evaluation  of  other  Service 
d  software  techniques  such  as  the  Joint  Logistics 
tware  standards,  and  the  new  testing  methods 
the  DoD  Software  Test  and  Evaluation  Project  (STEP) 


5.2  DoD,  Industry,  and  University  Contributions 


Several  DoD  and  private  sector  pro 
to  improve  the  state  of  practice  of  sof 
initiatives  Include  the  STARS  and  Ada  p 
Strategic  Computing  Program,  the  STEP, 
Research  Center.  The  Microelectronics 
Consortium  is  addressing  the  software-r 
Interface  and  early  requirements  and  de 
close  contact  with  the  planners  of  the 
Productivity  Consortium  to  ensure  that 
complementary. 


grams  have  been  initiated 
tware  technology.  The  DoD 
rograms ,  the  SEI,  DARPA's 
and  the  Super  Computing 
and  Computer  Technology 
elated  concerns  of  human 
sign.  STARS  is  maintaining 
still  embryonic  Software 
their  efforts  are 


The  SEI  has  been  established  to  bridge  the  gap  between  R&D 
activities  that  demonstrate  new  techniques  and  the  exploitation  of 
those  techniques  in  system  developments  in  order  to  effect  a 
significant  and  rapid  Improvement  in  the  means  of  development  and 
support  of  computer  software  for  mission-critical  defense 
systems.  The  Software  Engineering  Study  Panel  endorsed  the 
creation  of  the  SEI  to  be  a  central  driver  in  the  technology 
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,v  insertion  process.  The  SEI  was  designed  to  pool  scarce  resources, 

^  provide  goal-directed  technical  management,  select  high-payoff  and 

S  mutually-supportive  technologies,  engineer  selected  technologies 

to  mission  critical  scale  and  quality,  and  establish  visible 
standards  of  excellence  in  practice  and  ensure  that  they  are  met  ** 

by  the  whole  MCCR  software  community  (88). 

A  number  of  the  largest  defense  contractors  (and  some  smaller 
ones)  have  made  considerable  investments  in  the  development  of 
their  own  internal  software  engineering  environments.  With 

additional  funding,  it  would  be  possible  for  them  to  accelerate  '* 

the  development  of  these  software  engineering  environments  and  to 
tailor  them  more  closely  to  satisfy  DoD  needs  (89). 


5 . 3  Software  Technology  State  of  the  Art 

The  software  technology  state  of  art  offers  opportunities  to 
improve  the  state  of  practice.  The  software  engineering 
environment  is  one  example  of  a  state-of-the-art  software 
technology  that  is  currently  receiving  a  great  deal  of  attention 
in  the  literature.  In  spite  of  the  rapid  development  of  new  and 
potentially  superior  methods,  however,  techniques,  methods,  and 
practices  10  and  IS  years  old  are  routinely  used. 

5.3.1  Failure  to  Heed  Lessons  of  the  Past 


A  1979 
university 
that  lesson 
engineering 
account  for 
shortfalls , 
disciplined 
view  of  sof 


study  of  50  cases  from  government.  Industry,  and 
software  projects  in  the  Los  Angeles  area  estimates 
s  learned  and  published  18  years  earlier  in  software 
are  not  heeded  half  of  the  time.  Some  factors  that 
this  lag  include  rapid  technological  change,  education 
technology  transition  inhibitions,  resistance  to 
methods.  Inappropriate  role  models,  and  a  restricted 
tware  engineering  (30). 


5.3.2  Failure  to  Use  New  Methods 

A  study  of  seven  software-intensive  government  systems  and 
one  commercial  system  found  that  technologies  applied  during 
software  development  can  usually  be  traced  to  the  requirements  of 
the  military  standards  that  have  been  referenced  in  the 
contracts.  In  general,  developers  are  not  rewarded  for  exceeding 
the  minimum  technological  requirements  of  the  standards,  and  these 
developers  did  not  do  so.  Relatively  few  automated  tools  were 
available  or  used  by  any  of  the  projects  for  design,  coding, 
testing,  or  software  support  (31). 

of  several  companies  and  organizations 
rare  engineering  technologies  being  used  for 
snt  types.  For  the  most  part,  the  industry  at 
toftware  engineering  technologies  correctly. 

1 1 1 c s  of  the  software  development  environment 
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o  maintenance  is  rarely  performed  by  the  software  developer. 

The  report  also  observed  that  most  companies  are  willing  to  invest 
in  hardware  but  not  software.  Problems  with  the  current 
technology  include  the  inability  to  transport  tools  among  hardware 
and  the  failure  of  many  tools  to  live  up  to  promises  (18). 

5.3.3  New  Methods  Do  Exist 

Substantial  unexploited  software  technology  exists.  Some 
state-of-the-art  technologies  offer  the  ability  to  correct  many  of 
the  underlying  causes  of  the  problems  described  above,  but  are  not 
widely  used  (45),  (113),  (115)  -  (117).  Concrete  examples  of  some 
of  these  unexploited  software  technologies  are  found  in  (65). 

A  1982  document  (45),  drawing  from  several  Defense  Science 
Board  recommendations,  earlier  planning  documents,  and  independent 
recommendations  proposed  by  interested  and  concerned  groups, 
identified  and  assessed  13  areas  with  substantial  opportunities 
for  improving  the  software  technology  state  of  practice: 


(45). 


o  integrated  support  environments, 
o  system  definition  technologies, 
o  maintenance  techniques, 
o  reliability  technologies, 
o  database  technologies, 
o  distributed  systems, 
o  knowledge-based  systems, 
o  hardware/ software  synergy, 
o  human  factors, 
o  technology  transfer, 
o  measurement  technologies, 
o  management  tools  and  techniques  and 
o  applications-oriented  technologies  and 


software  reuse 


A  1983  conference  on  software  development  tools,  techniques, 
and  alternatives  identified  an  extensive  list  of  state-of-the-art 
technologies  with  the  potential  to  improve  the  state  of  the 
practice  Including: 


o  object  oriented  programming, 
o  software  management  tools, 

o  rapid  prototyping  and  application  generators, 


o  debugging  tools , 
o  software  design  tools, 

o  software  development  environments  and 
o  software  development  data  management  (46). 

A  1983  report  on  the  software  state  of  practice  made  some 
short-term  and  long-term  recommendations  for  improvement. 
Short-term  recommendations  included: 

o  making  available  more  and  better  computer  resources  for 
development ; 

o  evaluating  methods  and  tools; 

o  building  tool  support  for  a  common  high  level  language; 
o  improving  review  processes; 
o  using  incremental  development ;  and 
o  collecting  and  analyzing  data. 

For  the  long-term,  the  report  recommended: 

o  maintaining  compiler  technology; 
o  trying  prototyping; 

o  developing  test  and  evaluation  tools; 
o  examining  the  maintenance  process  and 
o  encouraging  Innovation  (18). 

A  1983  Air  Force  Scientific  Advisory  Board  Ad  Hoc  Committee 
on  Software  recommended  establishing  a  Software  Engineering  and 
Computer  System  Technology  and  Support  Center  to  collect  and  focus 
Air  Force  resources  on  software  issues.  It  contends  that  the  Air 
Force  must  have  a  central  organization  to  concentrate  and  focus 
the  R&D  expenditures  required  to  make  significant  improvements  in 
the  underlying  technology  essential  to  providing  the  needed 
technology  improvements  in  the  software  acquisition  and  production 
process.  In  addition,  it  recommends  increasing  Investment  for 
software  engineering  tooling  and  increasing  funding  for  long  range 
software  production  technology  research  to  Insure  the  acceleration 
of  advanced  technologies.  Such  technologies  include:  very  high 
order  languages,  applications  generators,  knowledge-based  systems, 
reuse  of  application  units,  and  verification  technology  (64). 

For  example,  it  has  been  estimated  that  Ada  will  reduce 
coding  effort  in  the  far-term  by  44%  for  applications  software 
development  and  40%  for  support  software.  Estimates  for  reduction 
in  lines  of  code  from  Ada  range  from  5  to  10%  in  the  near-term  to 
50%  in  the  long-term  (130).  Another  source  hypothesizes  a  75% 
improvement  in  coding  efficiency  from  the  continued  spread  of  new 
and  powerful  languages  such  as  Pascal  and  (possibly)  Ada  (131). 
Another  way  in  which  productivity  of  coding  might  be  improved  in 
the  "near"  future  is  finding  and  correcting  errors  in  groups  early 
on.  This  has  been  shown  to  translate  to  a  23%  increase  in 
productivity  of  coding  (134). 

Application  generators  and  formal  specification  and 
transformation  systems  also  show  promise.  Application  generators 
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are  software  packages  designed  to  help  end-users  build 
applications  in  a  given  domain.  Formal  specification  and 
transformation  systems  use  a  formal  specification  language  to 
express  system  design.  The  resulting  specification  is 
automatically  checked  for  consistency  and  completeness  after  which 
it  is  transformed  into  an  executable  program  either  by  automatic 
means  or  by  interaction  with  the  designer  (135). 


A  1985  Air  Force  Studies  Board  report  on  methods  to  improve 
software  quality  and  life  cycle  cost  made  several 
recommendations.  These  Included: 

o  Develop  first,  second,  and  third  generation  software 
engineering  environments  to  incorporate  Increasing  levels  of 
comprehensive  and  integrated  tools  and  techniques  such  as 
Artificial  Intelligence; 

o  Improve  management  of  software  in  the  acquisition, 
development,  and  operations  and  maintenance  phases  by 

-  increasing  use  of  prototyping, 

-  creating  centers  of  expertise  in  software, 

-  developing  software  management  tools, 

-  providing  better  training  -and  incentives,  and 

-  improving  procedures  for  selecting  managers. 

o  Promote  resuable  support  tools,  models,  subsystems,  and 
Ada  packages  (123). 

Careful  management  approaches  to  computer  development  and  the 
development  of  more  sophisticated  man-machine  interfaces  will 
improve  productivity.  Prototyping  and  reusable  code  and  design 
are  also  attractive  options  (135). 


Although 
opportunities 
This  indicate 
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the  level  of  detail  varies  in  the  lists  of 
presented  above,  there  is  overlap  between  them, 
s  agreement  on  certain  candidate  technologies  to 
tate  of  practice.  One  such  technology  that  has 
nsive  attention  over  the  past  few  years  is  the 
neering  environment  (47)  -  (51).  The  Japanese, 
pean  Community,  Brazilians,  and  many  U.S.  commercial 
re  embarking  on  the  development  of  such  systems.  The 
ripe  for  exploitation  of  this  technology  (52)  - 


The  Japanese  environment  project,  known  as  Sigma,  will 
develop  a  Japan-wide  Unix-based  network.  It  will  offer  four 
software  engineering  databases  for  software  modules,  software 
tools,  software  products,  and  technical  Information  (124).  The 
Alvey  Directorate  in  the  United  Kingdom  is  developing  three 
generations  of  Integrated  Project  Support  Environments.  The  first 
generation  will  be  a  file  based  Unix  system,  the  second  will  be 
database-oriented  with  a  distributed  operating  system,  and  the 
third  will  be  intelligent  (knowledge  based  system)  oriented 
(125).  Brazil  has  plans  to  develop  a  software  factory  (126). 
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The  European  Economic  Community  has  recently  made  a  $1 
billion  commitment  to  the  European  Strategic  Program  for  Research 
and  Development  in  Information  Technology  (ESPRIT)  (61).  ESPRIT 
pools  the  research  efforts  of  a  dozen  European  electronics  firms 
concerned  with  several  technologies,  including  software.  The 
ESPRIT  Project  is  funded  jointly  by  the  European  governments  with 
an  equal  amount  being  added  by  the  companies  (62). 

ESPRIT  is  working  on  the  development  of  a  Portable  Common 
Tool  Environment  (PCTE)  which  will  provide  a  common  base  for 
software  engineering  environments  aimed  at  supporting  European 
cooperative  research  and  development  and  at  fostering  widespread 
dissemination  and  exploitation  of  emerging  technologies,  methods, 
and  tools.  For  its  wide  availability,  Unix  is  expected  to  play 
the  role  of  “Initial  common  environment"  for  the  time  being 
(127).  To  date,  PCTE  specifications  have  been  developed. 

5.4  Summary  STARS  Program  Fills  Gap  and  Meets  Need 

Given  that  substantial  unexploited  software  technology  exists 
and  that  software  problems  and  requirements  have  much  in  common 
across  the  Services,  a  centrally  managed  DoD  software  improvement 
program  can  improve  the  state  of  practice  of  software  technology. 
Ada  and  the  Joint  Logistics  Commanders'  software  standards,  by 
fostering  uniformity  and  cooperation  among  the  Services  have 
prepared  the  DoD  community  sociologically  and  organizationally  for 
change.  The  time  is  now  right  for  a  centrally-managed  DoD  effort 
such  as  STARS  to  exploit  this  uniformity  among  the  Services  in 
order  to  improve  productivity  and  to  achieve  greater  system 
reliability  and  adaptability,  while  at  the  same  time,  coordinating 
the  efforts  of  the  private  sector  with  those  of  the  DoD 
laboratories  and  organizations  like  the  SEI  to  stimulate  R&D  and 
technology  insertion. 

STARS  will  provide  the  means  by  which  laboratories  and 
program  managers,  and  their  industry  counterparts  will  have  access 
to  usable  technology  products  vital  to  future  mission  critical 
systems.  The  SEI,  as  a  partner  to  STARS  will  encourage  and 
accelerate  the  transition  of  these  technology  products  into 
practice  with  respect  to  DoD  mission  critical  systems  (114). 

Their  use  could  also  aid  U.S.  international  competitiveness. 


6 . 0  Summary  of  the  Arguments 

Software  for  future  MCCR  systems  will  be  more  pervasive  and 
perform  more  functions  than  current  software.  Consequently,  it 
will  be  more  complex  and  critical  to  mission  success.  Moreover, 
there  is  a  growing  shortage  of  computer  personnel  to  meet  these 
needs.  The  future  software  state  of  practice  will  therefore  have 
to  plan  and  build  many  larger,  more  complex,  more  reliable,  and 
more  maintainable  systems  less  labor  intensively  than  the  current 
state  of  practice  does  today.  The  result  is  a  gap  between  the 


future  state  of  practice  requirements  and  the  current  state  of 
practice. 

To  compound  the  problem,  there  is  evidence  that  the  current 
state  of  practice  has  trouble  meeting  current  requirements. 

Often,  state-of-the-art  technologies  that  could  be  used  are  not. 
This  is  because  widespread  popularization  of  a  software  technology 
can  take  more  than  15-20  years.  The  opportunity  exists  to  reduce 
this  lag  by  undertaking  activities  that  will  facilitate  rather 
than  inhibit  technology  transition.  Thus,  as  Figure  1  indicates, 
accelerating  transition  of  the  state  of  the  art  into  the  state  of 
practice  can  be  used  to  close  the  technology  insertion  gap. 

In  those  areas  where  state-of-the-art  technologies  do  not 
exist  to  improve  the  state  of  practice,  R&D  must  be  fostered.  DoO 
activities,  industry,  and  academia  are  making  contributions  in 
this  area,  but  the  total  effort  is  too  big  an  undertaking  for  any 
one  entity. 

Therefore,  the  STARS  program  is  necessary  to  accelerate, 
coordinate  and  disseminate  the  results  of  R&D  in  software 
technology.  As  Figure  1  shows,  STARS  bridges  the  gulf  between 
future  and  current  software  technology  states  of  practice,  meeting 
the  need  for  an  improved  software  state  of  practice. 
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